A color-flagged agent now paints that color into the right quarter of its pane's session header, so a flag is spottable while scanning the grid — not only while scanning the Dispatch list.

 ┌────────────────────────────────────────────────┐
 │ A2  ~/dev/agent-code               ██████████  │ ◄ flag chunk, flush to the pane edge
 ├────────────────────────────────────────────────┤
 │  feed…                                         │

The chunk overlaps the status strip by design: liveness is automatic and transient, a flag is manual and sticky, so a user who flagged a pane red wants that red whether or not the agent happens to be running. The flag wins its slice.

What's here

• useColorFlag(sessionId) — the per-session lookup DispatchColorFlagStrip did inline, extracted so both surfaces resolve a flag identically. It returns a resolved ColorFlag, so every caller inherits the same "unknown persisted id → no flag" degradation. Geometry stays per-surface: a 10px alignment column and a 25% header chunk are different visual contracts.
• PaneHeaderColorFlag — the chunk. 25% proportional rather than a fixed width, because panes in a tiled grid vary enormously and a fixed chunk reads as a slab in a narrow lane and a rounding error in a wide one.
• PaneHeader — takes sessionId, renders the chunk as a trailing flex child.
• Copy fixes: the command description, palette module, and picker modal all claimed the flag renders only on a Dispatch row.

Two decisions worth a reviewer's attention

Unflagged renders nothing — deliberately the opposite of DispatchColorFlagStrip, which always mounts a transparent 10px column. That column exists to hold Dispatch labels in vertical alignment across rows; nothing sits to the right of this chunk, so there's no alignment invariant to protect, and reserving a quarter of every header would permanently squeeze the project dir for a signal that's switched off. The code comment records what would invert that reasoning.

The row's vertical padding moved down onto its label group. self-stretch fills the row's content box, so with py-1 on the row the chunk would float with a 4px gap top and bottom and read as a pill rather than a slice of the header. The same 4px still exists one level down, so rendered header height is unchanged. The row also went px-3 → pl-3 so the chunk reaches the pane edge without an absolute overlay or negative margin — the layout contract from docs/plans_and_ideas/2026-07-23-color-flag-layout-follow-up.md.

Names kept on purpose

Settings.dispatchColorFlags and the command id dispatch.color-flag.set still say "dispatch" though the flag now renders elsewhere. Both are persisted identifiers, not descriptions: the settings key would need a PERSIST_VERSION migration, and the command id keys Settings.commandVisibilityOverrides — renaming it silently drops a user's saved visibility choices. Recorded in a comment so the next reader doesn't "fix" it.

Verification

• npm run typecheck — clean. It caught a second PaneHeader consumer I'd missed: the remote client. It renders the same header and now passes sessionId too, resolving to "no flag" through its frozen DEFAULT_SETTINGS stub (dispatchColorFlags: {}). Wired honestly rather than stubbed out, so it lights up for free if the phone ever syncs settings.
• NODE_ENV=test npx vitest run — 1312/1312, 228 files, no flakes.
• npm run test:package — build + output verification pass.
• Coverage added to the existing DispatchColorFlags.renderer.test.tsx (no new test file): flagged header paints the palette color, unflagged renders no element at all, and the padding lives on the label group so the chunk can bleed.

Not done: the visual check. I didn't launch the app — a second Agent Code instance shares ~/.config/agent-code with your running one (sessions, tmux, proxy state), and that's not a risk worth taking unasked. The classes and colors are asserted in tests, but pixels are unconfirmed.

Plan: docs/superpowers/plans/2026-07-26-session-header-color-flag.md.

🤖 Generated with Claude Code